Mobile devices need to be configured with various settings to control and to provide various functions and support various services. One known method of configuration of mobile devices with service related data is via, for example, short message service (SMS) or wireless application protocol (WAP). This is a unidirectional path and to be able to perform bidirectional service, open mobile alliance (OMA) has specified protocols, data models and policies for device management (DM). As an example, OMA DM version 1.2.1 enabler release specifications defines how a DM session is established and maintained. One of the important functions in these specifications includes a bootstrap specification that describes methods for a device to be provisioned with OMA DM settings prior to initiating a management session. The OMA DM bootstrap technical specifications are described in OMA DM Bootstrap version 1.2., OMA-TS-DM Bootstrap VI—2—1. Open Mobile Alliance, June 2008.
Bootstrap is a process of provisioning a DM client of a mobile or a wireless device, to move the device from an un-provisioned, empty state, to a state where it is able to initiate a management session to a DM server and later to e.g. new DM servers. There are three different ways to perform a bootstrap process: customized bootstrap; server initiated bootstrap and bootstrap from a smartcard.
In the customized bootstrap process, devices are loaded with OMA DM bootstrap information at manufacture. This is also referred to as factory bootstrap.
In the server initiated bootstrap process, a server is configured to send out bootstrap information via some push mechanism e.g. WAP push. For this process, the server must receive the device address/phone number beforehand.
In the bootstrap process from the smartcard, the smartcard (e.g. subscriber identity module (SIM) or universal SIM (USIM)) is inserted in the device and the DM client is bootstrapped from the smartcard.
There are, however, several problems and drawbacks associated with systems using these processes. The customized bootstrap process requires that the basic parameters are known at the time of manufacture or at the time of selling the device. The server initiated bootstrap process specifies that the international mobile subscriber identity (IMSI) must be used to encode the basic DM parameters when the DM server performs a bootstrap over the air interface. This is done by sending an encrypted SMS with the basic parameters to the device. The key used for encryption is the IMSI for e.g. second generation/third generation network system, or the electronic serial number (ESN) for code division multiple access (CDMA) system. The IMSI or the ESN have however not been designed to be secret. This also means that the bootstrap message to be transmitted from the DM server to the device is weakly protected. As a result, an attacker can create its own bootstrap message in order to bootstrap a device that would be locked to a malicious DM server. Another drawback is that an attacker can eavesdrop the bootstrap message that is only integrity protected. Since the bootstrap message may contain credentials such as username and password, the attacker can impersonate the device.
FIG. 1 illustrated a high level view of a server initiated bootstrap process, as defined in the above cited specifications OMA DM Bootstrap version 1.2.1, OMA-TS-DM—Bootstrap V1—2—1. The scenario of FIG. 1 describing the service initiated bootstrap, shows a device 10, a user 11, a network 12 and a DM server (DMS) 13. In OMA-TS-DM—Bootstrap V1—2—1, it is described that once the user 11 acquires the device 10 and personalizes it, e.g. by inserting a SIM, the prerequisites for the bootstrapping process are in place. The DMS 13 is notified or informed of the identity, address or phone number of the device 10 by e.g. the network 12 the first time the device 10 registers to the network 12. When this happens a request to bootstrap the device 10 can be sent from the (core) network 12 to the DMS 13 with the number used by the device 10. The DMS 13 is now in a position where it can send out an OMA DM bootstrap message. This bootstrap message contains information for the device 10 to be able to initiate a management session with DMS 13 that sent out the bootstrap message.
The weak protection of the bootstrapping scenario described above, stems from the fact that the bootstrap message are, as mentioned above, only protected with a non-secret key (IMSI or ESN) as indicated in section 5.7.2.3.1 in OMA Device Management Security 1.2.1, OMA-TS-DM—Security-V1—2—1, OMA, 2008. Thus neither IMSI nor ESN is considered a shared secret from security standpoint. Similar OMA specifications also suffer from the same surety weaknesses, such as Enable Release Definition for OMA Client Provisioning Specifications version 1.2. OMAs-ERELD-ClientProvisioning-V1—1; and Provisioning Bootstrap 1.1. OMA-WAP-ProvBoot-V1—1.
It should be mentioned that these security vulnerabilities are the reasons why the security group (SA3) in the 3rd generation partnership project (3GPP) has issued a strong recommendation to not use the server initiated bootstrap method/process as indicated in 3GPP LS reply S3-080262.
Another prior art disclosed in US patent application US 2008/0155071 proposes a method and a system for bootstrap of a device in a communications network. In this prior art, a server initiated bootstrapping is used to first provision a smartcard of a device using over the air (OTA) technology so that the device can bootstrap from the smartcard. This is performed by combining bootstrap through the smartcard with the 3GPP automatic device detection (ADD) function. The 3GPP ADD, which is defined in the technical specification 3GPP TS 22.101, enables automatic detection of a device when the device appears in the network. However, the method of this prior art still relies on the lack of security of the current OMA DM specified Server Initiated bootstrap as described earlier.